CLOUD SECURITY - STRIKING THE RIGHT BALANCE:- ZERO STANDING ACCESS APPROACH FOR AWS ACCESS FROM CSCIS
Striking the right balance:- Zero Standing Access Approach for AWS Access from CSCIS
Introduction:
As we all are aware of the fact that Cloud consoles should be considered as Privileged Access. Insufficient access
control and unauthorised access due to credential theft and cookie stealing are the leading causes of many cloud
security incidents. Strong access control policies and practices, such as multi-factor authentication, least
privilege and providing just enough access, can help mitigate these risks.
The State of Cloud Permission Risks Report by Microsoft highlights a common issue in cloud service provider (CSP)
environments, where a significant number of identities are granted super admin permissions, even though they only
require a small subset of those permissions to perform their job functions.
State of Cloud Permission Risk Report
Super admin permissions provide a user with access to all areas of a cloud environment and the ability to perform
any action, which can make them a high-value target for attackers.
Current State:-According to a Microsoft Cloud Permission report, it is quite common for half of the identities
in cloud environments to be granted administrator access, and cloud team members often receive administrator
access for the entire AWS organization.
Below mentioned is the typical example what many of the organization may have adopted where any cloud or security
admin when logs into the AWS IAM identity centre, and simply gets Administrator Access across all the AWS Accounts
within an organization.

Typical Access for the Organization Cloud Team
Just imagine- If a rogue employee or someone with authorized access misuses their privileges or can be unauthorized
access via credential theft/cookie theft, it can cause significant damage to an organization. They could steal
sensitive data, modify or delete critical resources, or launch attacks on other systems or accounts. This could lead
to financial losses, legal liabilities, regulatory fines, damage to reputation, and other serious consequences.
To-Be State
Here are few thoughts organization can adopt to reduce the entire risk.
- First of all-No standing access at all. By default, employees should have no access at all whenever they access to the AWS IAM Identity Centre.
- To perform any task within the AWS env. With the help of external automation tool, user should get added automatically to the specific permission set for a given account for a specific timeframe only
Once timeframe expires, user should get removed automatically from the specific permission set. - In case of any Super Admin access such as AWS Administrator IAM Administrator access required for the Production accounts, users should go through the proper workflow approval.
Once approval are sought with a proper justification, user get added to the specific permission set for a specified timeframe. There are lot of tools out there for workflow approval such as ServiceNow, Slack, MSFT teams etc.
What’s the business value?
- Reduce the risk
- Theft of intellectual property, trade secrets, and other confidential information, which can be highly damaging to a company's competitive position and brand reputation.
- Regulatory and compliance considerations that must be taken into account when using cloud services. For example, companies may need to comply with data protection regulations such as GDPR or HIPAA, which can impose significant fines and legal liabilities in the event of a breach.
- To manage the Cyber Insurance Premium
- Here is potential risk reductions what businesses can consider for the proposed approach.
How to achieve it ?
- AWS provides the extensive API’s to manage access with the AWS IAM Identity centre. With the help of the automation tools, organization can provide the access on the fly.
- Here are few AWS CLI commands organization can leverage upon to add, delete or list users access for the specific permissions sets.
- https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/sso-admin/index.html#cli-aws-sso-admin
- List Assignments
- https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/sso-admin/list-account-assignments.html
- Example from my AWS environment:-
- aws sso-admin list-account-assignments --instance-arn arn:aws:sso:::instance/ssoins-8210b98ad604XXX --account-id 19XXXXXXXX --permission-set-arn arn:aws:sso:::permissionSet/ssoins-8210b98ad604XXXX/ps-1eb8baed86XXXXX
- Add Assignments
- https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/sso-admin/create-account-assignment.html
- Example from my AWS environment:-
- aws sso-admin create-account-assignment --instance-arn arn:aws:sso:::instance/ssoins-8210b98ad60XXXX --target-id 19533533XXXX --target-type AWS_ACCOUNT --permission-set-arn arn:aws:sso:::permissionSet/ssoins-8210b98ad60421e1/ps-1eb8baed86f84cc8 --principal-type USER --principal-id b9fab5fc-3061-70ae-f902-438bXXXXX
- Delete Assignments
- https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/sso-admin/delete-account-assignment.html
- Example from my AWS environment:-
- aws sso-admin delete-account-assignment --instance-arn arn:aws:sso:::instance/ssoins-8210b98ad60XXXX --target-id 19533533XXXX --target-type AWS_ACCOUNT --permission-set-arn arn:aws:sso:::permissionSet/ssoins-8210b98ad60421e1/ps-1eb8baed86fXXXX --principal-type USER --principal-id b9fab5fc-3061-70ae-f902-438bea4eXXXX
Author
